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SUBJECT: Application No. 10/091,237 - Requirement for Information 
under 37 CFR §1.105 

Applicant and the assignee of this application are required under 37 CFR §1.105 to 
provide the following information that the examiner has determined is reasonably 
necessary to the examination of this application. 

This information is being requested at this time because Examiner Stevens was made 
aware of the existence of documentation attributing the funding/sponsorship of the 
development of Applicant's subject matter to several different entities. 

Background 

The inventors have authored/presented papers in connection with the WIDM 
2001 conference that explicitly credited several diverse entities as "supporting" the 
development of the subject matter claimed by Applicants. It is unclear how ownership 
has been established, and whether the inventors of record had the right to assign the 
subject matter of this Application (10/091237) to the current assignee of record. 

The following entities were credited with providing support of Applicant's ' 
subject matter: 1) The National Science foundation (via the following vehicles: NSF 
NYI grant #IRI 94-57609, NSF CISE Instrumentation grant #IRIS 97-29878, and NSF 
grant #9988776); 2) HP (partial support of inventor Su via a HP Labs Grassroots Basic 
Research Grant; and, 3) IBM (support of inventor Su via an IBM Corporate Fellowship). 
See the paper downloaded from: www.cs.wpi.edu/~suhong/research/PAPERS/xtra- 
journal.ps, entitled "Automating the Transformation of XML Documents" (noting the 
bottom of page 1), which explicitly notes that Applicant's subject matter was supported 
via the vehicles noted above. See also, the PowerPoint presentation cited as Su, Hong, 



et al., "Automating Transformation of XML Documents", WIDM 2001 Powerpoint 
Presentation, Atlanta, Ga, Nov. 2001, pp. 1-29 (provided here and in the Action mailed 
11/28/2005), noting the last page (i.e., page 29), which thanked sponsors including NSF, 
HP and IBM. 

Additionally, it is noted that two of the named inventors, Su and Rundensteiner, 
were associated with Worcester Polytechnic Institute at the time of actual reduction to 
practice of the claimed subject matter. The Office notes that it is typical practice that 
university employees and students are under an obligation to assign the intellectual 
property that is the subject of their research to the university. 

The Information Requested 

Applicant and the assignee of this application are required under 37 CFR 1.105 to 
provide the following information that the Office has determined is reasonably 
necessary to the examination of this application. In response to this requirement, 
Applicant is required to address the following interrogatories, and to provide the 
following documents ... 



Interroeatories 

Please address the following interrogatories: 

1. What was the relationship of each inventor Su and Rundensteiner with 
Worcester Polytechnic Institute during the development of Applicant's subject matter? 
Were they students or employees? Please include time periods that these inventors were in 
such a relationship with Worcester Polytechnic Institute. 

2. Were Su and Rundensteiner under any obligation to assign the intellectual 
property during the development of Applicant's subject matter? 

3. Was Applicant's subject matter developed under a joint research 
agreement? If so, which entities entered into such an agreement? Per such agreement(s), 
which party was to own any intellectual property developed? 

4. Were federal funds used in the development of Applicant's subject matter? 
Why is there a discrepancy between what was stated on the record in the amendment filed 
7/31/2006 and what the inventors have explicitly stated in their papers/briefings? Why 
does Applicant maintain that the US Government has no rights in such research, which 
appears to have been developed, at least in part, using US Government funds? 

By way if background, Applicant has previously stated on the record that: 
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... there was no federally sponsored research and development. As such, no Federal 
statement [under MPEP §310] is necessary ... 

Refer to Applicant's amendment filed 7/31/2006 at page 10 lines 1-3. However, 
it is noted the inventors explicitly thanked NSF (i.e., the National Science Foundation, 
an independent US government agency responsible for promoting science and 
engineering through research programs and education projects) on page 29 of the Hong 
Su et al. briefing/PowerPoint presentation provided to Applicant on 11/28/2005. 
Additionally, the Office has uncovered a variant of the "Automating the 
Transformation of XML Documents'' paper by the inventors (downloaded from: 
www.cs.wpi.edu/-suhong/research/PAPERS/xtra-journal.ps), which explicitly sets forth 
NSF contractual vehicles (i.e., "several grants" including the grant contract numbers) 
used in funding the development of Applicant's subject matter. 

It is further noted that the "Automating the Transformation of XML Documents" 
paper was relied upon by the inventors to establish actual reduction to practice. (See 
the sections entitled "Reduction to Practice" and "Reduction to Practice Date" on pages 
2-3 of each of the Declarations filed under 37 CFR 1.131 for each of the three named 
inventors filed 10/17/2005.) Thus, these papers/briefings are all addressing the same, 
subject matter. 

5. What agreement was in place that relinquished any rights that IBM had in 
Applicant's subject matter? Why has only Hewlett Packard (and not IBM, for instance) 
been assigned rights in this invention? 

The inventors have also indicated that IBM supported the development of 
Applicant's subject matter. It is noted that one competitor (e.g., IBM) does not normally 
support the development of a product that is subsequently protected as intellectual 
property by another competitor. 

6. Was there a joint research agreement in place between IBM and Hewlett 
Packard concerning the development and ownership of rights in Applicant's subject 
matter? 

It is noted that Hong Su was sponsored by IBM under an IBM Corporate 
Fellowship. 
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Documents Requested 

The following documents are required to complete this requirement: 

1. Copies of agreements between Su and Worcester Polytechnic Institute, and 
Rundensteiner and Worcester Polytechnic Institute concerning their obligations as to assignment 
of intellectual property developed while employed by or as a student of Worcester Polytechnic 
Institute. 

2. Copies of agreements pertaining to #3 in the "Interrogatories" section above, 
which address joint research among sponsoring entities. 

3. Copies of each of the "several" NSF grants used to support the development of 
Applicant's subject matter, including, but not limited to: a) NSF NYI grant #IRI 94-57609; b) 
NSF CISE Instrumentation grant #IRIS 97-29878; and, c) NSF grant #9988776. 

4. A copy of any such agreement(s) referenced under #4 in the "Interrogatories" 
section above, concerning relinquishment of intellectual property rights by IBM. 

5. Copies of any agreements between Hong Su and IBM concerning the ownership 
of intellectual property rights developed under the IBM Corporate Fellowship. 



Non-patent Literature: 

The following Non-Patent Literature has been provided in the Office Action 
accompanying this communication: 

Su, Hong, et al., "Automating Transformation of XML Documents", WIDM 2001, 
Atlanta, GA, Nov. 2001, pp. 1-25. (downloaded in PDF format from: 
www.cs.wpi.edu/-suhong/research/PAPERS/xtra-journal.ps) 

Su, Hong, et al., "Automating Transformation of XML Documents", WIDM 2001 
Powerpoint Presentation, Atlanta, GA, Nov. 2001, pp. 1-29. Note: This document was 
previously provided with the Office Action mailed 11/28/2005. It is provided again as a 
courtesy to Applicant, as it is referenced in the attached Requirement For Information. 



In responding to those requirements that require copies of documents, where the 
document is a bound text or a single article over 50 pages, the requirement may be met 
by providing copies of those pages that provide the particular subject matter indicated 
in the requirement, or where such subject matter is not indicated, the subject matter 
found in applicant's disclosure. 
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The fee and certification requirements under 37 CFR §1.97 are waived for those 
documents submitted in reply to this requirement. This waiver extends only to those 
documents within the scope of this requirement under 37 CFR §1.105 that are included 
in the applicant's first complete communication responding to this requirement. Any 
supplemental replies subsequent to the first communication responding to this 
requirement and any information disclosures beyond the scope of this requirement 
under 37 CFR §1.105 are subject to the fee and certification requirements of 37 CFR 
§1.97. 

The applicant is reminded that the reply to this requirement must be made with candor 
and good faith under 37 CFR §1.56. Where the applicant does not have or cannot 
readily obtain an item of required information, a statement that the item is unknown or 
cannot be readily obtained will be accepted as a complete response to the requirement 
for that item. 

This requirement is an attachment of the enclosed Office action. A complete reply to 
the enclosed Office action must include a complete reply to this requirement. The 
time period for reply to this requirement coincides with the time period for reply to 
the enclosed Office action. 
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Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Robert Stevens whose telephone number is (571) 272- 
4102. The examiner can normally be reached on M-F 6:00 - 2:30. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, John E. Breene can be reached on (571) 272-4107. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published 
applications may be obtained from either Private PAIR or Public PAIR. Status 
information for unpublished applications is available through Private PAIR only. For 
more information about the PAIR system, see http://pair-direct.uspto.gov. Should you 
have questions on access to the Private PAIR system, contact the Electronic Business 
Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO 
Customer Service Representative or access to the automated information system, call 
800-786-9199 (IN USA OR CANADA) or 571-272-1000. 





TECHNOLOGY CENTER 2100 
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Application/Control Number: 10/091 ,237 Page 2 

Art Unit: 2162 

DETAILED ACTION 
Response to Arguments 

1. Applicant's arguments with respect to the claims have been considered but are moot in 
view of the new ground(s) of rejection addressing the amended claim language. Only arguments 
directed to the combination of the previously cited art have been addressed below. 

Additionally, regarding claims 1 and 10 Applicant further argues on pages 9-10 that the 
XEM and SchemaMatching references are not properly combined, because "both XSLT and 
Lexus cannot serve in the scenario where structure is required". See Applicant's amendment 
page 15 lines 2-8. 

The Office respectfully disagrees. It is unclear what Applicant is arguing here, because 
"Lexus" is described as a system employed by a reference cited at the end of the XEM paper. 
Section 6 is entitled "Related Work" because it describes what competitors are doing in the field 
of endeavor. Lexus has nothing to do with either the SchemaMatching or the XEM references, 
other than a mere mention as a system developed by Infozone Group that operates in a similar 
field of endeavor. Neither XEM, nor SchemaMatching, rely on Lexus. XEM, therefore, does 
not teach away from the use of the teachings of SchemaMatching. 

Applicant sets forth substantially the same arguments regarding the combinability of 
references and "Lexus" on pages 11-15 regarding claims 17 and 18, and those claims dependent 
upon claim 18, as that set forth above concerning claims 1 and 10. 
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The Office respectfully disagrees, re-iterating the counter arguments set forth above 
concerning claims 1 and 10. 

Applicant sets forth substantially the same arguments regarding the combinability of 
references and "Lexus" on pages 13-14 regarding claims 5-9 and 20-26 as that set forth above 
concerning claims 1 and 10. 

The Office respectfully disagrees, re-iterating the counter arguments set forth above 
concerning claims 1 and 10. 

For at least these reasons, the Office asserts the rejections of the claims as set forth 

below. 

Continued Examination Under 37 CFR 1.114 
2. A request for continued examination under 37 CFR 1.114, including the fee set forth in 
37 CFR 1 .17(e), was filed in this application after final rejection. Since this application is 
eligible for continued examination under 37 CFR 1.1 14, and the fee set forth in 37 CFR 1.17(e) 
has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 
37 CFR 1.114. Applicant's submission filed on 1/16/2006 has been entered. 
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Application/Control Number: 1 0/091 ,237 Page 4 

Art Unit: 2162 

Claim Rejections - 35 USC § 112 

3. The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

4. Claim 17 is rejected under 35 U.S.C. 112, second paragraph, as being indefinite for 
failing to particularly point out and distinctly claim the subject matter which applicant regards as 
the invention. This claim is vague and ambiguous, and thus, its scope is indeterminable. 

Regarding claim 17: The scope of this claim is unclear as it appears to reiterate a 
limitation that already exists in parent claim 10. 



Claim Rejections - 35 USC §103 

5. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 

obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed 
or described as set forth in section 102 of this title, if the differences between the 
subject matter sought to be patented and the prior art are such that the subject 
matter as a whole would have been obvious at the time the invention was made to 
a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was 
made. 
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6. Claims 1, 3-4 and 10-16 are rejected under 35 U.S.C 103(a) as being unpatentable 
over Hong Su et al. ("Identification of Syntactically Similar DTD Elements for Schema 
Matching", The Second International Conference on Web-Age Information Management (Waim 
2001V Xi'an, China, July 2001, pp. 1-13, hereafter referred to as "SchemaMatching") in view of . 
Hong Su et al. ("XEM: Managing the Evolution of XML Documents", Eleventh International 
Workshop on Research Issues in Data Engineering (RIDE 2001V Heidelberg, Germany, April 1- 
2, 2001, pp. 1-8,. hereafter referred to as U XEM") and further in view of Hellman et al. (US 
Patent Application Publication No. 2004/0216030, filed via continuation on May 25, 2001 and 
published Oct. 28, 2004, hereafter referred to as "Hellman"). 



Independent claim 1 states: 

A method of document transformation comprising: 

a) modeling source XML document corresponding to a source schema as a source 
tree having a plurality of source nodes; 

b) modeling target XML document corresponding to a target schema as a target 
tree having a plurality of target nodes; and 

c) generating a sequence of transformation operations that transforms said 9 
source tree to said target tree, said sequence of transformation operations utilizing an 
extensible stylesheet language for transformations (XSLT) generator to translate the 
sequence of transformation operations into an equivalent XSLT transformation script and 
utilize the transformation script to transform an input XML document corresponding to 
the source schema to the target XML document corresponding to the target schema. 

Regarding these limitations ... 

a) modeling source XML document corresponding to a source schema as a source tree 
having a plurality of source nodes; 

b) modeling target XML document corresponding to a target schema as a target tree having 
a plurality of target nodes; and 

SchemaMatching discloses DTD schema matching in the Abstract, discussing the 

matching of elements between two DTD schemas. SchemaMatching further discusses in 
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Example 1 of page 2, the modeling of DTD schemas for a customer (i.e., source) and a client 
(i.e., target) as DTD graphs. Figure 1 of page 5 shows (arranged as tree data structures) the 
element graphs for the customer and client DTDs, and section "2.3 Construction of a Directed 
Acyclic Graph (DAG)" describes the process of creating the DAG, or tree, data structure. 

c) generating a sequence of transformation operations that transforms said source tree to 
said target tree, 

However, SchemaMatching does not explicitly disclose the generation of a sequence of 
transformation operations. XEM, though, teaches the application of a series of transformation 
operations in section "4 Completeness of DTD Change Operations" on pages 6-7, discussing a 
proof for the generation of a target DTD (e.g., G') from a source DTD (e.g., G) via a finite 
sequence of operations (e.g., U F()" ). XEM further discloses a working framework, dubbed • 
"Marrow", the implemented the concepts disclosed by XEM, and was demonstrated at the ACM 
SIGMOD 2000. (See page 7 section "5 System Implementation: MARROW" and Footnote 1.) 
Additionally, XEM discusses the application of DTD change primitives to child nodes in order to 
ensure the validity of the target DTD in section "3.2 DTD Change Primitives". 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of XEM for the benefit of SchemaMatching, because to do so would have 
allowed a designer to change a DTD without requiring change of underlying XML data, as 
taught by XEM in top left paragraph of page 2. These references were all applicable to the same 
field of endeavor, i.e., XML programming. 
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said sequence of transformation operations utilizing an extensible stylesheet language for 
transformations (XSLT) generator to translate the sequence of transformation operations into 
an equivalent XSLT transformation script and utilize the transformation script to transform 
an input XML document corresponding to the source schema to the target XML document 
corresponding to the target schema. 

SchemaMatching does not explicitly disclose a hardware implementation environment. 

Hellman, though, teaches the conversion of XML expressions into an XSLT script for 

transforming a source data schema into data conforming to a target data schema in paragraphs 

[0065] - [0066]. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of Hellman for the benefit of SchemaMatching in view of XEM, because 
to do so would have provided a tool for transforming a first and a second schema and have 
allowed companies to readily use each other's databases for sharing data, as taught by Hellman 
in paragraphs [0049] - [0050]. These references were all applicable to the same field of 
endeavor, i.e., XML programming. 

Regarding dependent claim 3, SchemaMatching discloses matching leaf vertices (i.e., 
nodes of a tree) in section "3.1 Initial Leaf Vertices Matching" on pages 5-6, discussing 
operational steps for "Matching Criterion 1" between leaf nodes. Discussion of "Matching 
Criterion 2" in section "4 Detection of Hierarchically Equivalent Elements" on page 7, discloses 
a stricter set of rules for matching leaf nodes that includes consideration of the tree hierarchy to 
the nodes being matched. 



Application/Control Number: 10/091,237 
Art Unit: 2162 



Page 8 



Regarding dependent claim 4, SchemaMatching does not explicitly disclose the 
generation of a sequence of transformation operations. XEM, though, teaches the application of 
a series of transformation operations in section "4 Completeness of DTD Change Operations" on 
pages 6-7, discussing a proof for the generation of a target DTD (e.g., G') from a source DTD 
(e.g., G) via a finite sequence of operations (e.g., "F()" ). XEM further discloses a working 
framework, dubbed "Marrow", the implemented the concepts disclosed by XEM, and was 
demonstrated at the ACM SIGMOD 2000. (See page 7 section "5 System Implementation: 
MARROW" and Footnote 1 .) Additionally, XEM discusses the application of DTD change 
primitives to child nodes in order to ensure the validity of the target DTD in section "3.2 DTD 
Change Primitives". 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of XEM for the benefit of SchemaMatching, because to do so would have 
allowed a designer to change a DTD without requiring change of underlying XML data, as 
taught by XEM in top left paragraph of page 2. These references were all applicable to the same 
field of endeavor, i.e., XML programming. 



Independent claim 10 states: 

A method of document transformation comprising: 

a) modeling a source schema of XML and a target schema of XML as a tree 
structure creating source tree and a target tree, said source tree having a plurality of 
source nodes, said target tree having a plurality of target nodes; and 

b) generating a sequence transformation operations that transforms said source 
XML document to said target XML document, wherein said plurality of source nodes of 
said source schema are matched and transformed to said plurality of target nodes in said 
target schema, said sequence of transformation operations utilizing an extensible 
stylesheet language for transformations (XSLT) generator to translate the sequence of 
transformation operations into an equivalent XSLT transformation script and utilize the 
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transformation script to transform an input XML document corresponding to the source 
schema to the target XML document corresponding to the target schema. 

Regarding these limitations ... 

a) modeling a source schema of XML and a target schema of XML as a tree structure 
creating source tree and a target tree, said source tree having a plurality of source nodes, said 
target tree having a plurality of target nodes; and 

wherein said plurality of source nodes of said source schema are matched and transformed 
to said plurality of target nodes in said target schema, 

SchemaMatching discloses DTD schema matching in the Abstract, discussing the 

matching of elements between two DTD schemas. SchemaMatching further discusses in 

Example 1 of page 2, the modeling of DTD schemas for a customer (i.e., source) and a client 

(i.e., target) as DTD graphs. Figure 1 of page 5 shows (arranged as tree data structures) the 

element graphs for the customer and client DTDs, and section "2.3 Construction of a Directed 

Acyclic Graph (DAG)" describes the process of creating the DAG, or tree, data structure. 

SchemaMatching discloses matching leaf vertices (i.e., nodes of a tree) in section "3.1 Initial 

Leaf Vertices Matching" on pages 5-6, discussing operational steps for "Matching Criterion 1" 

between leaf nodes. Discussion of "Matching Criterion 2" in section "4 Detection of 

Hierarchically Equivalent Elements" on page 7, discloses a stricter set of rules for matching leaf 

nodes that includes consideration of the tree hierarchy to the nodes being matched. 

SchemaMatching also discloses three exemplary methods of transforming DTD elements on 

page 3. 

b) generating a sequence transformation operations that transforms said source XML 
document to said target XML document, 

However, SchemaMatching does not explicitly disclose the generation of a sequence of 

transformation operations. XEM, though, teaches the application of a series of transformation 
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operations in section "4 Completeness of DTD Change Operations" on pages 6-7, discussing a 
proof for the generation of a target DTD (e.g., G') from a source DTD (e.g., G) via a finite 
sequence of operations (e.g., "FQ" ). XEM further discloses a working framework, dubbed 
"Marrow", the implemented the concepts disclosed by XEM, and was demonstrated at the ACM 
SIGMOD 2000. (See page 7 section u 5 System Implementation: MARROW" and Footnote 1.) 
Additionally, XEM discusses the application of DTD change primitives to child nodes in order to 
ensure the validity of the target DTD in section "3.2 DTD Change Primitives". 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of XEM for the benefit of SchemaMatching, because to do so would have 
allowed a designer to change a DTD without requiring change of underlying XML data, as 
taught by XEM in top left paragraph of page 2. These references were all applicable to the same 
field of endeavor, i.e., XML programming. 

said sequence of transformation operations utilizing an extensible stylesheet language for 
transformations (XSLT) generator to translate the sequence of transformation operations into 
an equivalent XSLT transformation script and utilize the transformation script to transform 
an input XML document corresponding to the source schema to the target XML document 
corresponding to the target schema. 

SchemaMatching does not explicitly disclose a hardware implementation environment. 

Hellman, though, teaches the conversion of XML expressions into an XSLT script for 

transforming a source data schema into data conforming to a target data schema in paragraphs 

[0065] - [0066]. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of Hellman for the benefit of SchemaMatching in view of XEM, because 
to do so would have provided a tool for transforming a first and a second schema and have 
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allowed companies to readily use each other's databases for sharing data, as taught by Hellman 
in paragraphs [0049] - [0050]. These references were all applicable to the same field of 
endeavor, i.e., XML programming. 

Regarding dependent claim 11, SchemaMatching discloses matching nodes and 
selecting a best matching plan in phases numbered 3 and 4 on page 2 (immediately above the 
section labeled "2 DTD Data Model"). SchemaMatching also discloses distance (i.e., cost) and 
element overlap (i.e., data loss) in Example 4 of page 7, and the paragraph preceding Example 4, 
which discuss computing a number reflective of the amount of overlap of two graphs. 



Regarding dependent claim 12, SchemaMatching does not explicitly disclose the 
generation of a sequence of transformation operations. XEM, though, teaches the application of 
a series of transformation operations in section "4 Completeness of DTD Change Operations" on 
pages 6-7, discussing a proof for the generation of a target DTD (e.g., G') from a source DTD 
(e.g., G) via a finite sequence of operations (e.g., U F()" ). XEM further discloses a working 
framework, dubbed "Marrow", the implemented the concepts disclosed by XEM, and was 
demonstrated at the ACM SIGMOD 2000. (See page 7 section "5 System Implementation: 
MARROW" and Footnote 1.) Additionally, XEM discusses the application of DTD change 
primitives to child nodes in order to ensure the validity of the target DTD in section "3.2 DTD 
Change Primitives". 
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It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of XEM for the benefit of SchemaMatching, because to do so would have 
allowed a designer to change a DTD without requiring change of underlying XML data, as 
taught by XEM in top left paragraph of page 2. These references were all applicable to the same 
field of endeavor, i.e., XML programming. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of XEM for the benefit of SchemaMatching, because to do so would have 
allowed a designer to change a DTD without requiring change of underlying XML data, as 
taught by XEM in top left paragraph of page 2. These references were all applicable to the same 
field of endeavor, i.e., XML programming. 

Regarding dependent claim 13, SchemaMatching discloses the use of source and target 
DTDs in phase number "1." above the section entitled "2 DTD Data Model", discussing 
modeling source and target DTDs as graphs. 

Regarding dependent claim 14, SchemaMatching discloses simplifying DTDs into a 
reduced DTD in section "2.1 Simplification Transformation on DTD", discussing, for example, a 
transformation that folds a group into a flattened representation. 
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Regarding dependent claim 15, SchemaMatching discloses simplifying DTDs into a 
reduced DTD in section "2.1 Simplification Transformation on DTD", discussing, for example, a 
transformation that merges sub-elements having the same name in a content model. 

Regarding dependent claim 16, SchemaMatching does not explicitly disclose 
constraining node operations. XEM, though, teaches the well-known use of quantifier node 
notation, such as qmark "?", asterisk "*" and plus "+" in sub-section 2. Constraint Node" on 
page 3. XEM further discusses labelling in the third paragraph bleow the section header "2.2 
The DTD Data Model", discussing the labelling function / (i.e., "ell"). XEM discloses on pages 
3-6 various operations performed on DTD models. In section "2.2 The DTD Data Model", XEM 
sets forth how nodes are labelled and the notation used by one skilled in the art at the time of the 
invention. Section "3.2 DTD Change Primitives" sets forth various operations using that 
notation, including folding or flattening (see page 5 "5. flattenGroup(E, pos)") [it being obvious 
that one performed the inverse of folding in order to unfold], and the changing of attributes 
[including relabeling] in section "3.2.3 Changes to an Attribute Type Definition" on page 6. 

When certain functions are performed is merely an obvious variant. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of XEM for the benefit of SchemaMatching, because to do so would have 
allowed a designer to change a DTD without requiring change of underlying XML data, as 
taught by XEM in top left paragraph of page 2. These references were all applicable to the same 
field of endeavor, i.e., XML programming. 



0 
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7. Claim 17-18 and 20-21 are rejected under 35 U.S.C 103(a) as being unpatentable over 
Hong Su et al. ("Identification of Syntactically Similar DTD Elements for Schema Matching", 
The Second International Conference on Web-Age Information Management (Waim 200 1\ 
Xi'an, China, July 2001, pp. 1-13, hereafter referred to as "SchemaMatching") in view of Hong 
Su et al. ("XEM: Managing the Evolution of XML Documents", Eleventh International 
Workshop on Research Issues in Data Engineering (RIDE 200 \\ Heidelberg, Germany, April 1- 
2, 2001, pp. 1-8, hereafter referred to as "XEM") and further in view of Hellman et al. (US 
Patent Application Publication No. 2004/0216030, filed via continuation on May 25, 2001 and 
published Oct. 28, 2004, hereafter referred to as "Hellman") and Swamy et al. (US Patent No. 
6,874,141, filed Jun. 29, 2000 and issued Mar. 29, 2005, hereafter referred to as "Swamy"). 

Regarding dependent claim 17, SchemaMatching does not explicitly disclose the 
generation of XSLT stylesheets. Swamy, though, teaches generation of XSLT stylesheets in the 
Abstract, discussing the generation of XSL code representation (and an XSLT stylesheet) of a 
mapping between a source and a target schema. 

It would have been obvious to one of ordinary skill in the art at the time of the inventipn 
to apply the teachings of Swamy for the benefit of SchemaMatching in view of XEM and 
Hellman, because to do so would have allowed one to compile a graphical representation of data 
transformations into an XSL stylesheet representation of the mapping, as taught by Swamy in 
col. 3 lines 19-25. These references were all applicable to the same field of endeavor, i.e., XML 
programming. 
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Independent claim 18 states: 

A computer system comprising: 
a processor; and 

a computer readable memory coupled to said processor and containing program 
instructions that, when executed, implement a method of document transformation 
comprising: 

a) modeling source XML document corresponding to a source schema as a source 
tree having a plurality of source nodes; 

b) modeling target XML document corresponding to a target schema as a target 
tree having a plurality of\target nodes; and 

c) generating a sequence of transformation operations that transforms said 
source tree said target tree, said sequence of transformation operations utilizing an 
extensible stylesheet language for transformations (XSLT) generator to translate the ■ 
sequence of transformation operations into an equivalent XSLT transformation script and 
utilize the transformation script to transform an input XML document corresponding to 
the source schema to the target XML document corresponding to the target schema. 



Regarding these limitations ... 

a) modeling source XML document corresponding to a source schema as a source tree 
having a plurality of source nodes; 

b) modeling target XML document corresponding to a target schema as a target tree having 
a plurality of target nodes; and 

SchemaMatching discloses DTD schema matching in the Abstract, discussing the 

matching of elements between two DTD schemas. SchemaMatching further discusses in 
Example 1 of page 2, the modeling of DTD schemas for a customer (i.e., 'source) and a client 
(i.e., target) as DTD graphs. Figure 1 of page 5 shows (arranged as tree data structures) the 
element graphs for the customer and client DTDs, and section "2.3 Construction of a Directed 
Acyclic Graph (DAG)" describes the process of creating the DAG, or tree, data structure. 
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c) generating a sequence of transformation operations that transforms said source tree to 
said target tree. 

However, SchemaMatching does not explicitly disclose the generation of a sequence of 
transformation operations. XEM, though, teaches the application of a series of transformation 
operations in section "4 Completeness of DTD Change Operations" on pages 6-7, discussing a 
proof for the generation of a target DTD (e.g., G 5 ) from a source DTD (e.g., G) via a finite 
sequence of operations (e.g., "F()" ). XEM further discloses a working framework, dubbed 
"Marrow", the implemented the concepts disclosed by XEM, and was demonstrated at the ACM 
SIGMOD 2000. (See page 7 section "5 System Implementation: MARROW" and Footnote 1.) 
Additionally, XEM discusses the application of DTD change primitives to child nodes in order to 
ensure the validity of the target DTD in section "3.2 DTD Change Primitives". 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of XEM for the benefit of SchemaMatching, because to do so would have 
allowed a designer to change a DTD without requiring change of underlying XML data, as 
taught by XEM in top left paragraph of page 2. These references were all applicable to the same 
field of endeavor, i.e., XML programming. 

said sequence of transformation operations utilizing an extensible stylesheet language for 
transformations (XSLT) generator to translate the sequence of transformation operations into 
an equivalent XSLT transformation script and utilize the transformation script to transform 
an input XML document corresponding to the source schema to the target XML document 
corresponding to the target schema; 

SchemaMatching does not explicitly disclose a hardware implementation environment. 

Hellman, though, teaches the conversion of XML expressions into an XSLT script for 

transforming a source data schema into data conforming to a target data schema in paragraphs 

[0065] - [0066]. 
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It would have been obvious to one of ordinary skill in the art at t he time of the invention 
to apply the teachings of Hellman for the benefit of SchemaMatching in view of XEM, because 
to do so would have provided a tool for transforming a first and a second schema and have 
allowed companies to readily use each other's databases for sharing data, as taught by Hellman 
in paragraphs [0049] -.[0050]. These references were all applicable to the same field of 
endeavor, i.e., XML programming. 

a processor; and 

a computer readable memory coupled to said processor and containing program 
instructions that, when executed, implement a method of document transformation 
comprising; 

SchemaMatching does not explicitly disclose a hardware implementation environment. 
Swamy, though, teaches a hardware implementation environment in Figure 15, disclosing a 
processor (#521) and memory units (#522, 527, 529, 531) coupled via a bus (#523) for executing 
applications (#536), including source to target schema transformations (Abstract). 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of Swamy for the benefit of SchemaMatching in view of XEM and 
Hellman, because to do so would have allowed one to compile a graphical representation of data 
transformations into an XSL stylesheet representation of the mapping, as taught by Swamy in 
col. 3 lines 19-25. These references were all applicable to the same field of endeavor, i.e., XML 
programming. 
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Regarding dependent claim 20, SchemaMatching discloses matching leaf vertices (i.e., 
nodes of a tree) in section "3.1 Initial Leaf Vertices Matching" on pages 5-6, discussing 
operational steps for "Matching Criterion 1" between leaf nodes. Discussion of "Matching 
Criterion 2" in section "4 Detection of Hierarchically Equivalent Elements" on page 7, discloses 
a stricter set of rules for matching leaf nodes that includes consideration of the tree hierarchy to 
the nodes being matched. 

Regarding dependent claim 21, SchemaMatching does not explicitly disclose the 
generation of a sequence of transformation operations. XEM, though, teaches the application of 
a series of transformation operations in section "4 Completeness of DTD Change Operations" on 
pages 6-7, discussing a proof for the generation of a target DTD (e.g., G') from a source DTD 
(e.g., G) via a finite sequence of operations (e.g., "F()" ). XEM further discloses a working 
framework, dubbed "Marrow", the implemented the concepts disclosed by XEM, and was 
demonstrated at the ACM SIGMOD 2000. (See page 7 section "5 System Implementation: " 
MARROW" and Footnote 1.) Additionally, XEM discusses the application of DTD change 
primitives to child nodes in order to ensure the validity of the target DTD in section "3.2 DTD 
Change Primitives". 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of XEM for the benefit of SchemaMatching in view of Hellman and 
Swamy, because to do so would have allowed a designer to change a DTD without requiring 
change of underlying XML data, as taught by XEM in top left paragraph of page 2. These 
references were all applicable to the same field of endeavor, i.e., XML programming. 
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8. Claims 5-9 are rejected under 35 U.S.C 103(a) as being unpatentable over Hong Su et 
al. ("Identification of Syntactically Similar DTD Elements for Schema Matching", The Second 
International Conference on Web- Age Information Management (Waim 2001) . Xi'an, China, 
July 2001, pp. 1-13, hereafter referred to as "SchemaMatching") in view of Hong Su et al. 
("XEM: Managing the Evolution of XML Documents", Eleventh International Workshop on 
Research Issues in Data Engineering (RIDE 2001V Heidelberg, Germany, April 1-2, 2001, pp. 1- 
8, hereafter referred to as "XEM") and further in view of Hellman et al. (US Patent Application 
Publication No. 2004/0216030, filed via continuation on May 25, 2001 and published-Oct. 28, 
2004, hereafter referred to as "Hellman") and Peter Buneman et al ("UnQL: A Query Language 
and Algebra for Semi Structured Data Based on Structural Recursion", The VLDB Journal . Issue 
No. 9, Springer- Verlag, © 2000, pp. 76-1 10, hereafter referred to as "Buneman"). 

Regarding dependent claims 5-6 and 8-9, SchemaMatching discloses matching source 
and target nodes and generating a transformation between nodes in phases 3 and 4 on page 2, 
discussing the matching likelihood of component pairs" (phase 3) and producing a "best 
matching plan" in phase 4. However, SchemaMatching does not explicitly disclose computing 
for a sequence of transformation operations, such as unfolding. Buneman, though, teaches the 
calculation of value equivalence in performing operations on trees in section "4.1 value 
Equivalence" starting on page 88, discussing the determination of a value equivalence for a data 
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graph d and the resulting graph from an unfold operation in the first and second paragraphs under 
the section heading. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of Buneman for the benefit of SchemaMatching in view of XEM and 
Hellman, because to do so would have allowed one to implement a value-based semistructured 
data model, as taught by Buneman in last paragraph on page 77. These references were all 
applicable to the same field of endeavor, i.e., XML programming. 

Regarding dependent claim 7, SchemaMatching does not explicitly disclose matching 
node labels. XEM, though, teaches the use of node labels in section "2.2 The DTD Data Model", 
discussing a labeling for node attributes. It was implicit in node matching that at least one node 
attribute must be matched, and it was a obvious variant at the time of the invention as to which 
attribute (e.g. label name) was matched between nodes. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of XEM for the benefit of SchemaMatching in view of Hellman and 
Buneman, because to do so would have allowed a designer to change a DTD without requiring 
change of underlying XML data, as taught by XEM in top left paragraph of page 2. These 
references were all applicable to the same field of endeavor, i.e., XML programming. 
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9. Claims 22-26 are rejected under 35 U.S.C. 103(a) as being unpatentable over Hong Su 
et al. ("Identification of Syntactically Similar DTD Elements for Schema Matching", The Second 
International Conference on Web- Age Information Management (Waim 200 1\ Xi'an, China, 
July 2001, pp. 1-13, hereafter referred to as "SchemaMatching") in view of Hong Su et al. 
("XEM: Managing the Evolution of XML Documents", Eleventh International Workshop on 
Research Issues in Data Engineering (RIDE 2001V Heidelberg, Germany, April 1-2, 2001, pp. 1- 
8, hereafter referred to as "XEM") and further in view of Hellman et al. (US Patent Application 
Publication No. 2004/0216030, filed via continuation on May 25, 2001 and published Oct. 28, 
2004, hereafter referred to as "Hellman") and Swamy et al. (US Patent No. 6,874,141, filed Jun. 
29, 2000 and issued Mar. 29, 2005, hereafter referred to as "Swamy") and Peter Buneman et al 
("UnQL: A Query Language and Algebra for Semi Structured Data Based on Structural 
Recursion", The VLDB Journal . Issue No. 9, Springer- Verlag, © 2000, pp. 76-1 10, hereafter' 
referred to as "Buneman"). 

Regarding dependent claims 22-23 and 25-26, SchemaMatching discloses matching 
source and target nodes and generating a transformation between nodes in phases 3 and 4 on 
page 2, discussing the matching likelihood of component pairs" (phase 3) and producing a "best 
matching plan" in phase 4. However, SchemaMatching does not explicitly disclose computing 
for a sequence of transformation operations, such as unfolding. Buneman, though, teaches the 
calculation of value equivalence in performing operations on trees in section "4.1 value 
Equivalence" starting on page 88, discussing the determination of a value equivalence for a data 
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graph d and the resulting graph from an unfold operation in the first and second paragraphs under 
the section heading. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of Buneman for the benefit of SchemaMatching in view of XEM and - 
further in view of Hellman and Swamy, because to do so would have allowed one to implement a 
value-based semistructured data model, as taught by Buneman in last paragraph on page 77. 
These references were all applicable to the same field of endeavor, i.e., XML programming. 

Regarding dependent claim 24, SchemaMatching does not explicitly disclose matching 
node labels. XEM, though, teaches the use of node labels in section "2.2 The DTD Data Model", 
discussing a labeling for node attributes. It was implicit in node matching that at least one node 
attribute must be matched, and it was a obvious variant at the time of the invention as to which 
attribute (e.g. label name) was matched between nodes. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of XEM for the benefit of SchemaMatching in view of Hellman, Swamy 
and Buneman, because to do so would have allowed a designer to change a DTD without 
requiring change of underlying XML data, as taught by XEM in top left paragraph of page 2. 
These references were all applicable to the same field of endeavor, i.e., XML programming. 
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Conclusion 

10. The prior art made of record and not relied upon is considered pertinent to applicant's 
disclosure. 
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